📝 本系列為 iThome 鐵人賽學習筆記,屬個人教學與非商業用途;文中法規與標準內容均以自身理解後的話轉述並註明出處,非逐字引用。
階段二|誰在管、用什麼管:制度與標準

Day 6 把《人工智慧基本法》的權責架構立了起來——誰是主管機關、誰訂綱領、誰管風險分類。但對開發者而言,光知道「誰在管」還不夠實用,真正想問的是下一個問題:這部法,到底要求我這個做 AI 產品的人做什麼?
今天就把基本法課予的實質義務攤開來看。它們集中在四件事上:如何依風險分級管理、什麼樣的應用要受更嚴的把關(高風險)、出了事誰負責(責任歸屬與救濟),以及要不要標示與揭露。 這四件事,每一件都會直接影響你的產品設計與工程決策,而不只是法務部門的紙上作業。
先講一個貫穿今天的心法:基本法在義務這一塊,走的是**「以風險為基礎(risk-based)」**的路線——風險越高的應用,要承擔的義務就越重;風險低的應用,則盡量不增加不必要的負擔。這個「風險比例原則」,是理解後面所有規定的鑰匙。
依第 16 條,風險分類的責任分成兩層:
這裡要特別提醒一件容易誤會的事:基本法本身,並沒有像某些人以為的那樣,直接列出「第一級、第二級、第三級」這種明確的風險等級表。 它做的是「授權」——授權數位部去「建立框架」、授權各部會去「依框架訂規範」。
換句話說,此刻(2026 年)具體的分級標準、每一級對應哪些義務,大多仍在框架與作用法的研擬階段。這正是 Day 1 講的縫隙在「風險分類」這個主題上的具體樣貌。對開發者的意義是:你現在無法從法條裡查到一張「我的產品屬於第幾級」的對照表,但你可以、也應該先用「風險越高、標準越嚴」的原則,自行評估自己的產品大概落在光譜的哪一端。
第 16 條特別點明框架要「參考國際標準、與國際接軌」。這不是隨口一提——它意味著台灣的風險分類,會刻意向國際主流靠攏,特別是歐盟《人工智慧法》(EU AI Act)的風險分級思維。這條線,Day 14 對接國際時會完整展開;今天先記住:把 AI 依風險分級管理,是一個全球趨勢,不是台灣獨有。
在整個風險光譜中,基本法特別點出了一個需要更嚴格對待的類別——高風險應用。它從認定到義務的整條流程如下圖所示,以下逐段拆解。

依第 5 條第 2 項,高風險應用不是由開發者自己說了算,而是由中央目的事業主管機關會商數位部來認定。也就是說,判斷「這類 AI 應用算不算高風險」的權力,握在你所屬領域的主管部會手上(會同數位部)。
基本法也點出一個特別受保護的對象:本項並明定政府應以兒少最佳利益為原則——涉及兒童及少年的 AI 應用,會受到更審慎的檢視。
一旦被認定為高風險,基本法目前明確課予的義務是:應明確標示注意事項或警語(第 5 條第 2 項)。同時,依第 5 條第 3、4 項,數位部及相關機關應提供或建議評估驗證的工具與方法,且這些工具的形成要徵詢產業、學者、社會團體與法律專家的意見。
換句話說,高風險不只是貼個標籤,還連帶牽動「要用什麼工具來驗證它安全」的問題——這條線,直接通往第三階段(Day 15–20)要談的台灣本土評測驗證體系。
雖然精確清單尚待作用法明定,但從第 5 條第 1 項列舉的「應避免」情事,可以合理推測方向:凡是 AI 的輸出可能侵害人民生命、身體、自由、財產,或造成歧視、資訊誤導、破壞社會秩序與國家安全的應用,就是高風險的候選。落到實務,醫療診斷輔助、金融信用評分、司法量刑參考、關鍵基礎設施控制這類「錯了會出大事」的場景,通常會是各部會優先鎖定的對象。
風險管理的另一面,是「出事了誰負責」。依第 17 條,政府應就高風險 AI 的應用,明確其責任歸屬與歸責條件,並建立救濟、補償或保險機制。
這條對產業有一個很實際的設計:第 17 條第 2 項給了研發階段的豁免——AI 在實際應用「之前」的研發,不適用前項的責任規定;但一旦進入實際環境測試,或用研發成果去提供產品、服務,豁免就結束。這是在「鼓勵創新」與「保護權益」之間取的平衡:讓研發者敢於嘗試,但產品一落地服務真實使用者,責任就跟上。
對開發者的啟示是:你的系統從「實驗」跨到「上線服務」的那一刻,合規責任的等級就跳升了。 把這條線畫清楚,是專案規劃時的重要判斷。
前三項義務偏管理層次,而這一項,是最會直接改變你產品畫面的。
基本法裡與揭露相關的規定有兩處,層次不同,要分清楚:
一個常被討論的具體應用,是AI 生成內容的揭露——當內容(文字、圖片、影音)是由 AI 生成時,讓使用者知道「這是 AI 產生的」。這正呼應第 4 條第 5 款的透明原則。精確的揭露格式與範圍,仍待作用法細化,但方向已經明確:AI 不該假裝自己是人,AI 的產出也不該讓人誤以為是真實或人為的內容。
把這些義務翻成使用者體驗(User Experience,以下簡稱 UX)語言,會長出幾個具體的設計要求。如下圖所示,它們最後都落在使用者看得到的介面上:

這些不是可有可無的裝飾,而是把法律義務內建進介面。及早在設計階段就考慮進去,遠比上線後被要求補救來得省力。
今天多次提到「與國際接軌」。這裡先做一個對照的預告,Day 14 會完整展開;台灣與歐盟兩種取向的差別,可先參照下圖。

歐盟《人工智慧法》採取的是明確的四級風險分類:不可接受風險(直接禁止)、高風險(受最嚴格義務)、有限風險(主要是透明義務)、最小風險(幾乎不管制)。台灣基本法目前的做法則是**「以風險為基礎的框架 + 高風險類別」**,把明確的分級標準留給數位部的框架與各部會的作用法去長出來。
兩者的精神一致——風險越高、管得越嚴——但成熟度與明確度不同:歐盟已把等級寫死在母法,台灣則採「原則入法、框架與細則另訂」的漸進路線。這個差異,正是本系列反覆強調的縫隙,在國際對照下看得最清楚。
今天的制度義務,如何落到本系列的 RAG 客服範例上?整理成一條可執行的鏈路,如下圖所示,逐項說明如下:

於是,一條看似抽象的「透明與可解釋」義務,最後會變成 RAG 系統輸出層的幾行程式與一份稽核紀錄。這就是「從法條到程式碼」在義務層面的具體示範。
今天把基本法課予的實質義務盤點完畢:
明天(Day 8)將深入基本法的價值核心——第 4 條的七大原則。 今天談的義務多半源自這七大原則,明天會逐條拆解每一條原則的意涵,並延續本系列的做法,把每一條原則對映到一個具體的技術落地動作,為第二階段後半的 ISO/IEC 42001 鋪路。